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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The present document defines the coding of information in an extension of the Base Station System AppHcation Part 
(BSSAP) that is needed to support location services on interfaces based on use of BSSAP. 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies procedures and information coding that are needed to define and support the BSSAP 
LCS Extension (BSSAP-LE). The BSSAP-LE message set is appHcable to the following GSM interfaces defined in 
3GPP TS 43.059: 

- Lb interface (BSC-SMLC). 

- Lp interface (SMLC-SMLC). 

The present document defines message formats and encoding for BSSAP-LE and the particular subsets of it that are 
applicable to each of the above interfaces. The present document also defines the support for BSSAP-LE message 
transfer on each of these interfaces using either ITU-T and ANSI versions of SS7 MTP or IETF M3UA/SCTP and 
SCCP. Additional requirements for the above interfaces that are applicable to BSSAP-LE are also defined - e.g. usage 
of BSSAP (as defined in 3GPP TS 24.008 and 48.008) on the Lb interface. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[la] 3GPP TS 23.032: "Universal Geographical Area Description (GAD)". 

[2] 3GPP TS 43.059: "Functional Stage 2 Description of Location Services in GERAN". 

[3] 3GPP TS 44.018: "Mobile radio interface layer 3 specification; Radio Resource Control Protocol". 

[3a] 3GPP TS 24.008: "Mobile radio interface layer 3 specification; Core Network Protocols; Stage 3". 

[4] 3GPP TS 44.03 1 : "Location Services (LCS); Mobile Station (MS) - Serving Mobile Location 

Center (SMLC); Radio Resource LCS Protocol (RRLP)". 

[5] 3GPP TS 44.071: "Location Services (LCS); Mobile radio interface layer 3 Location Services 

(LCS) specification". 

[6] 3GPP TS 48.006: "Signaling transport mechanism specification for the Base Station Subsystem - 

Mobile-services Switching Centre (BSS - MSC) interface". 

[7] 3GPP TS 48.008: "Mobile-services Switching Centre - Base Station System (MSC-BSS) 

interface; Layer 3 specification". 

[8] 3GPP TS 48.03 1 : "Location Services (LCS); Serving Mobile Location Center - Serving Mobile 

Location Center (SMLC - SMLC); SMLCPP specification". 

[9] 3GPP TS 48.071: "Serving Mobile Location Center - Base Station Subsystem (SMLC -BSS) 

interface Layer 3 specification". 

[10] 3GPP TS 29.002: "Mobile Apphcation Part (MAP) specification". 

[10a] 3GPP TS 23.003: "Numbering, addressing and identification". 
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[11] ITU-T Recommendation Q.702: "Signalling data link" . 

[ 1 2] ITU-T Recommendation Q.703 : "Signalling link" . 

[13] ITU-T Recommendation Q.704: "Signalling network functions and messages". 

[14] ITU-T Recommendation Q.707: "Testing and maintenance". 

[15] ITU-T Recommendation Q.711: "Functional description of the signalling connection control part" . 

[16] ITU-T Recommendation Q.712: "Definition and function of signalling connection control part 

messages". 

[17] ITU-T Recommendation Q.713: "Signalling connection control part formats and codes". 

[18] ITU-T Recommendation Q.714: "Signalling connection control part procedures". 

[19] ANSI Tl.lll (1996): "Signalling System Number 7 - Message Transfer Part". 

[20] ANSI Tl.l 12 (1996): "Signalling System Number 7 (SS7) - Signalling Connection Control Part 

Functional Description". 

[21] TlA/ElA/lS-J-STD-036 (2000): "Wireless Enhanced Emergency Services". 

[22] 3GPP TS 48.018: "General Packet Radio Service (GPRS); Base Station System (BSS) - Serving 

GPRS Support Node (SGSN); BSS GPRS Protocol (BSSGP)". 

[23] IETF STD 51, RFC 1661(07/1994): "The Point-To-Point Protocol (PPP)". 

[24] IETF STD 51, RFC 1662(07/1994): "PPP in HDLC-like Framing". 

[25] IETF RFC 2507(02/1999): "IP header compression". 

[26] IETF RFC 1990(07/1994): "The PPP MultiHnk Protocol (MP)". 

[27] IETF RFC 2686(09/1999): "The Multi-Class Extension to Multi-Link PPP". 

[28] IETF RFC 2509(02/1999): "IP Header Compression over PPP". 

[29] 3GPP TS 29.202: "SS7 Signalhng Transport in Core Network; Stage 3". 

[30] Galileo OS SIS ICD/D.O "Gahleo Open Service, Signal In Space Interface Control 

Document/Draft 0". 

3 Definitions, abbreviations and symbols 

For the purposes of the present document, the definitions, symbols and abbreviations listed in 3GPP TS 21.905 and 
3GPP TS 43.059 apply. 



Definition of BSSAP-LE 



BSSAP-LE is an extension to BSSAP that contains messages and parameters specific to the support of LCS. The 
following subsets of BSSAP-LE are defined: DTAP-LE, BSSMAP-LE. 



4.1 DTAP-LE Messages 



DTAP-LE messages are transfered between an SMLC and a Type A LMU and comprise the following individual 

messages: 

- REGISTER; 

- FACILITY; 
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- RELEASE COMPLETE. 

The content, encoding and certain procedures asssociated with DTAP-LE messages are defined in 3GPP TS 44.07 L 

4.2 BSSMAP-LE Messages 

BSSMAP-LE messages are transferred between a BSS and SMLC and comprise the following individual messages: 
BSSMAP-LE Positioning Messages: 

Perform Location Request; 

Perform Location Response; 

Perform Location Abort; 

Perform Location Information. 
BSSMAP-LE Information Messages: 

Connection Oriented Information; 

Connectionless Information. 
BSSMAP-LE General Messages: 

Reset; 

Reset Acknowledge. 
The content and encoding of BSSMAP-LE messages are defined in the present document. 

5 Procedures applicable to use of BSSAP-LE 



5.1 Location Request 



The Location Request procedure is applicable to the Lb interface. Its purpose is to obtain a location estimate for a target 
MS that is already in dedicated mode, in packet transfer mode, in packet idle mode, or in dual transfer mode. It is also 
used to provide an MS with LCS assistance data or with a deciphering key for LCS broadcast assistance data. The 
initiator of a location request is the BSS. The procedure makes use of SCCP connection oriented signaling on the Lb 
interface. 
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5.1.1 Successful Operation 



The initiator of the location request sends a BSSMAP-LE Perform Location Request to the SMLC associated with the 
current serving cell for the target MS. The message contains the following mandatory (M), conditional (C) and optional 
(O) information, where conditional parameters are required if available. 

Location Type (M). 

- GANSS Location Type (C) 

- Cell Identifier (M). 

Classmark Information Type 3 (C). 

- LCS Client Type (C). 
Chosen Channel (C). 

- LCS Priority (C). 

- LCS QoS (C). 

Requested GPS Assistance Data (C). 

- BSSLAP APDU (C). 

- LCS Capability (O). 

Packet Measurement Report (O). 

- Measured Cell Identity List (O). 

- IMSI of target MS (O). 

- IMEI of target MS (O). 

- Requested GANSS Assistance Data (C). 

If requested, the SMLC performs positioning of the target MS using a particular position method or a combination of 
more than one positioning method. If neither the Classmark Information Type 3 IE nor the LCS Capability IE is present, 
the SMLC shall instigate only network based positioning methods (e.g. TA and U-TDOA but not GPS or E-OTD). 

Alternatively, if requested otherwise, the SMLC may provide positioning assistance data to the MS. The SMLC may 
invoke the following other BSSAP-LE procedures to perform these procedures: 

connection oriented information transfer; 

connectionless information transfer; 

LMU connection establishment; 

LMU connection release; 

DTAP-LE information transfer. 

Additional procedures defined in 3GPP TS 24.008 and 3GPP TS 48.008 may also be performed. If a location estimate 
was requested and was subsequently obtained, the SMLC shall return a BSSMAP-LE Perform Location Response to the 
initiator of the location request. This message contains the following mandatory, conditional and optional parameters. 

- Location Estimate (M). 
Positioning Data (C). 

- GANSS Positioning Data (C). 

Restrictions on the geographic shape encoded within the Location Estimate parameter may exist for certain LCS client 
types. The SMLC shall comply with any restrictions defined in 3GPP specifications and, in a particular country, with 
any restrictions defined for a specific LCS client type in relevant national standards. For example, in the US, national 
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interim standard TIA/EIA/IS-J-STD-036 [21] restricts the geographic shape for an emergency services LCS client to 
minimally either an "ellipsoid point" or an "ellipsoid point with uncertainty circle and confidence" as defined in 
3GPPTS 23.032. 

If assistance data was instead requested for an MS and the SMLC was able successfully to transfer this to the MS, the 
SMLC shall return a BSSMAP-LE Perform Location Response to the initiator of the location request (serving BSC). 
This message shall contain no parameters. The absence of an LCS Cause parameter in this case implies that the transfer 
was successful. 

Otherwise, if a deciphering key was requested for LCS broadcast assistance data and the SMLC has access to the 
appropriate keys, the SMLC shall return a BSSMAP-LE Perform Location Response to the initiator of the location 
request. This message contains the following mandatory parameters. 

Deciphering Keys (M). 



5.1.2 Unsuccessful Operation 



If the SMLC is unable to obtain any of the location information requested or if requested LCS assistance data could not 
be transferred or requested deciphering keys for broadcast assistance data could not be returned, the SMLC shall return 
a BSSMAP-LE Perform Location Response to the initiator of the Location Request carrying the following parameters: 

- LCS Cause (M); 
Positioning Data (O). 

- GANSS Positioning Data (O). 

If assistance data or deciphering keys for a specific positioning method is not supported in the network or in the location 
area, the SMLC shall indicate this with LCS Cause value "Position method failure" accompanied with diagnostic value 
"Position Method Not Available in Network" or "Position Method Not Available in Location Area". 

5.1.3 Abnormal Conditions 

If an ongoing location request is preempted at the initiator by an inter-BSC handover or if the main signaling link to the 
target MS is lost or released or if there is a timeout waiting for the positioning response, or if there is an Inter NSE cell 
change in the PS Domain (e.g. detected by the BSS at receipt of BSSGP FLUSH-LL PDU) for which the BSS is unable 
to maintain the positioning procedure, the initiator shall send a BSSMAP-LE Perform Location Abort to the SMLC 
containing the following parameters. 

- LCS Cause (M). 

On receipt of this message, the SMLC shall stop positioning of the target MS and may release any resources 
(e.g. LMUs) previously allocated. If the SMLC has not yet returned a BSSMAP-LE Perform Location Response to the 
initiator, it shall return this message containing an LCS Cause indicating an abort and, optionally, positioning data, 
GANSS positioning data. The initiator shall then release the SCCP connection. If the SMLC cannot proceed with 
positioning due to some protocol violation or error condition (e.g. inter-BSC handover indication received from the 
serving BSC), it shall return a BSSMAP-LE Perform Location Response to the initiator containing an LCS cause and, 
optionally, positioning data, GANSS positioning data. The initiator need not reply at the BSSAP-LE level to this 
message. However, the initiator may return a BSSMAP-LE perform Location Abort which shall not be treated as an 
error by the SMLC. 

5.1.4 Overload 

If the SMLC is in an overload condition, it may reject a BSSMAP-LE Perform Location request by returning a 
BSSMAP-LE Perform Location response containing an LCS Cause parameter indicating congestion. The initiator of the 
location service request (BSC) may reduce the frequency of future location service requests until rejection due to 
overload has ceased. In reducing the frequency of location service requests, a BSC shall reduce lower priority requests, 
to zero if necessary, before reducing the frequency of higher priority requests. An SMLC shall similarly reject location 
service requests of a lower priority, to zero if necessary, due to overload before rejecting location service requests of a 
higher priority. An SMLC in an overload condition may optionally employ the following procedures to alleviate 
overload: 
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a) Allow higher priority location service requests to preempt lower priority requests for which location service 
procedures are already in progress. 

b) Abort lower priority location service requests already in progress. 

c) Reduce the supported QoS for lower priority requests for a location estimate - e.g. by reducing accuracy or 
increasing response time. 

d) Employ MS based positioning methods, where supported by the target MS and SMLC, rather than MS assisted 
or network based methods (except TA). 

The priority of a location service request shall be defined according to the value in the LCS Priority parameter. If this 
parameter is absent in a BSSMAP-LE Perform Location request, the lowest priority shall be assumed. 

5.2 Connection Oriented Information Transfer 

The Connection Oriented Information transfer procedure is applicable to the Lb interface. It enables two way transfer of 
BSSLAP messages between an SMLC and the BSS serving a target MS. The initiator of the procedure can be either the 
ESS serving the target MS or the SMLC. The procedure is only valid while a location request procedure for the target 
MS is ongoing. The procedure makes use of SCCP connection oriented signaling on the Lb interface and uses the same 
SCCP connection as the location request procedure for the particular target MS. 

5.2.1 Successful Operation 

An SMLC or BSS with a BSSLAP message to transfer concerning a particular target MS sends a BSSMAP-LE 
Connection Oriented Information message to a recipient carrying the following parameters: 

- BSSLAP APDU (M); 

(Segmentation (C)). 

If the sender is an SMLC, the message is transferred to the BSS. The BSS shall then perform the positioning operation 
requested by the BSSLAP APDU (refer to 3GPP TS 48.071). If the BSSLAP APDU contains an RRLP APDU, the BSS 
shall transfer this to the target MS. 

If the sender is a BSS and the intended recipient is the SMLC for a target MS, the message is transferred to the SMLC. 
The SMLC shall then perform interpretation of the BSSLAP APDU. 

5.2.2 Abnormal Conditions 

At an intermediate entity, if a received BSSMAP-LE Connection Oriented Information message contains unrecognized 
information or if the message cannot be sent on, the message shall be discarded. 

At the recipient entity, if a received BSSMAP-LE Connection Oriented Information message contains invalid or 
unrecognized information as defined for BSSAP-LE, any ongoing positioning procedure shall be terminated and 
associated resources may be released. If the recipient is a BSS, the SMLC shall be notified - e.g. using a BSSLAP 
Reject or Abort. If the recipient is an SMLC, a new positioning attempt (e.g. using a different position method) may be 
started. 

If a BSS receives an error from SGSN after having attempted to transfer the information via SGSN to an MS for PS 
domain positioning, the BSS shall notify the SMLC with a BSSLAP Abort message. 

5.2.3 Segmentation 

Segmentation is only included for support of interoperability with Legacy (3GPP R4 and older) equipment when a 
segmented message is received from a Legacy node. 3GPP R5 and later equipment shall not initiate the use of 
segmentation. 

The Segmentation parameter shall not be included if the BSSLAP message is not segmented. 
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If the size of an embedded BSSLAP message is too large to fit into one BSSMAP-LE message, the sending entity 
divides the BSSLAP message to a necessary number of BSSMAP-LE messages each containing a BSSLAP APDU IE 
and a Segmentation IE. In the BSSLAP APDU IE it includes as many octets as possible. 

The segmentation IE contains a segment number field and an indication of the final segment. Message identification 
shall not be used. The order number of a segment in the Segment Number field in the Segmentation IE is incremented 
by one starting from zero, i.e. the value is for the first segment, 1 for the next and so on. The receiving entity may use 
the segment number in order to recognize the start of a new BSSLAP message and verify that all segments were reliably 
transferred. 

In case of handover interrupting the information transfer procedure, the exception procedures described in 
3GPP TS 43.059 shall be used. 

5.3 Connectionless Information Transfer 

The Connectionless Information transfer procedure is applicable to the Lb and Lp interfaces. It enables two way transfer 
of LLP messages between an SMLC and a Type B LMU. The procedure also enables two way transfer of SMLCPP 
messages between two SMLCs. The initiator of the procedure can be a BSS or SMLC. The procedure makes use of 
SCCP connectionless signaling. 

5.3.1 Successful Operation 

An SMLC or BSS needing to transfer an LLP message concerning a Type B LMU or an SMLCPP message sends a 
BSSMAP-LE Connectionless Information message to a recipient carrying the following parameters: 

- Source Entity (M); 
Destination Entity (M); 

- APDU (M); 

- Segmentation (C); 

Return Error Request (O). 

The source entity identifies the sender. The recipient entity identifies the final destination. The Segmentation IE 
provides segmentation and message identification for a segmented APDU. The Return Error Request may be included 
to request notification in the event of unsuccessful transfer and indicate the type of notification needed. If the recipient 
entity is not the final destination, the recipient shall transfer the BSSMAP-LE Connectionless Information message to 
either the final destination or an intermediate entity capable of onward transfer to the final destination. 

5.3.2 Unsuccessful Operation 

If the message cannot be transferred by an intermediate entity or destination entity (e.g. reassembly of a segmented 
message fails) and the Return Error Request is not included, the message shall be discarded. If the Return Error Request 
is included, the intermediate or destination entity shall, depending on the Return Error Request type, send a 
BSSMAP-LE Connectionless Information message to, or towards, the original source containing the following 
parameters: 

- Source Entity (M); 
Destination Entity (M); 

- APDU (C); 

Segmentation (C); 

Return Error Cause (M). 

The Source entity shall indicate the Destination Entity in the original received message. The Destination Entity shall 
indicate the Source Entity in the original message. The Return Error cause shall indicate the reason for unsuccessful 
transfer. The APDU and Segmentation lEs shall, depending on the Return Error Request type, contain any originally 
received APDU and Segmentation lEs, respectively. 
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If a received BSSMAP-LE Connectionless Information message containing a Return Error Cause cannot be transferred 
by an intermediate entity, it shall be discarded with no return error message. 

5.3.3 Abnormal Conditions 

At an intermediate entity, if a received BSSMAP-LE Connectionless Information message contains unrecognized or 
invalid information, the message shall be discarded. 

At the recipient entity, if a received BSSMAP-LE Connectionless Information message contains invalid or 
unrecognized information as defined for BSSAP-LE, the message shall be discarded. 

5.3.4 Segmentation 

The Segmentation parameter shall not be included if the APDU is not segmented. 

If the size of an APDU containing an embedded SMLCPP message is too large to fit into one BSSMAP-LE message, 
the sending entity divides the SMLCPP message to a necessary number of BSSMAP-LE messages each containing an 
APDU IE and a Segmentation IE. In the APDU IE it includes as many octets as possible. 

The segmentation IE contains a segment number, an indication of the final segment and the message ID. The order 
number of a segment in the Segment Number field in the APDU IE is incremented by one starting from zero, i.e. the 
value is for the first segment, 1 for the next and so on. The receiving entity recognizes that a segment is missing or 
duplicated, when: 

There is more than one segment with the same segment number and same Message ID. 

The segment number does not increase by steps of one starting from zero. 

If the recipient recognizes a missing or duplicated element, it shall discard the entire message (i.e. all received segment 
with the message ID). 

The message identity in the Message ID field in the APDU IE is used to recognize a particular message to which that 
segment belongs. The sending entity can select any of the available values (0-65535) that is not currently used between 
it and the receiving entity. 

If an APDU segment is received with Return Error cause IE (due to invocation of the return error option), reassembly 
does not apply and the APDU segment and error cause maybe returned to the original source application. 

5.4 LMU Connection Establishment 

The LMU Connection Establishment procedure is applicable to the Ls interface. Its purpose is to establish a signaling 
connection between an SMLC and Type A LMU via the visted MSC for the LMU. The procedure can be initiated by 
either the SMLC or MSC. The procedure makes use of SCCP connection oriented signaling on the Ls interface. 

5.4.1 LMU Connection Establishment initiated by the SMLC 
5.4.1.1 Successful Operation 

The SMLC sends a BSSMAP-LE LMU Connection Request message to the VMSC for the LMU. This message 
contains the following parameters. 

- IMSI (M). 
Sender Address (O). 

- Security (C). 

The IMSI identifies the LMU. The sender address, if included, identifies the SMLC. The Security parameter shall be 
included if authentication or ciphering of the LMU are required. On receipt of this message, the MSC shall attempt to 
establish a signalling link to the LMU (refer to 3GPP TS 43.071). Authentication and ciphering shall be invoked if 
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requested by the SMLC. Once the signaling link has been established, the MSC shall return a BSSMAP-LE LMU 
Connection Accept to the SMLC with the following parameters. 

- Call Number (O). 

The call number shall be included if the MSC has the capability to support signaling to an LMU using a traffic channel 
(refer to 3GPPTS 43.071). 

5.4.1.2 Unsuccessful Operation 

If the LMU is not recognized in the MSC (e.g. no VLR record) or a signaling link cannot be setup to the LMU 
(e.g. paging of the LMU fails) or authentication or ciphering cannot be performed when requested by the SMLC, any 
signaling link to the LMU shall be released, if not required for other MM or CM procedures and a BSSMAP-LE LMU 
Connection Reject shall be returned to the SMLC with the following parameters. 

- Reject Cause (M). 

5.4.1.3 Abnormal Conditions 

If the SMLC or MSC detects release of the SCCP connection on the Ls interface for an LMU, the connection 
establishment procedure shall be considered to have failed and any associated resources may be released. 

5.4.2 LMU Connection Establishment initiated by the MSC 

5.4.2.1 Successful Operation 

The MSC shall initiate the LMU connection establishment procedure when no LMU connection to the SMLC currently 
exists and the MSC receives a CM Service Request from the LMU specifying the LCS service. The MSC shall then 
send a BSSMAP-LE LMU Connection Request message to the SMLC associated with either the IMSI or current cell 
location of the LMU. This message shall contain the following parameters. 

- IMSI (M). 

- Sender Address (M). 

- Call Number (C). 

The IMSI identifies the LMU. The sender address identifies the MSC. The call number shall be included if the MSC has 
the capability to support signaling to an LMU using a traffic channel (refer to 3GPP TS 43.071). On receipt of this 
message, the SMLC shall return a BSSMAP-LE LMU Connection Accept to the MSC with the following parameters. 

- Security (C). 

The Security parameter shall be included if authentication or ciphering of the LMU are required On receipt of this 
message, the MSC shall perform authentication and/or ciphering if requested by the SMLC and shall complete the 
establishment of an MM connection to the LMU to support LCS. 

5.4.2.2 Unsuccessful Operation 

If the LMU is not recognized in the SMLC or a signaling connection cannot be supported (e.g. due to congestion), a 
BSSMAP-LE LMU Connection Reject shall be returned to the MSC with the following parameters. 

- Reject Cause (M). 

The MSC shall then reject the CM service request from the LMU. 

5.4.2.3 Abnormal Conditions 

If the SMLC or MSC detects release of the SCCP connection on the Ls interface for an LMU, the connection 
establishment procedure shall be considered to have failed and any associated resources may be released. 
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5.5 (void) 

5.6 DTAP-LE Information Transfer 

The DTAP-LE Information transfer procedure is applicable to the Lb interface. It supports two way LLP message 
transfer between an SMLC and Type A LMU. The procedure is only valid when a signaling connection between an 
SMLC and Type A LMU has been established. The procedure uses SCCP connection oriented signaling using the 
SCCP connection previously established between the SMLC and BSC when the signaling connection between the 
SMLC and LMU was established. 

5.6.1 DTAP-LE Information Transfer Initiated by the SMLC 

The SMLC initiates the procedure when it has an LLP message to transfer to a type A LMU. The message may first be 
segmented. The SMLC shall then transfer each LLP segment to the BSC inside a DTAP-LE REGISTER, FACILITY or 
RELEASE COMPLETE message. The usage of these messages is as defined in 3GPP TS 44.071. The BSC relays each 
DTAP-LE message to the LMU. 

5.6.2 DTAP-LE Information Transfer Initiated by the BSC 

The BSC initiates the procedure when a DTAP message is received from an LMU. The BSC then relays the DTAP 
message to the SMLC. 

5.7 Reset 

The reset procedure is an optional procedure within a PLMN applicable to the Lb interface. It enables an SMLC or BSS 
that has undergone a failure with loss of memory of LMU signalling connections and location service transactions to 
indicate this to a partner entity (SMLC or BSS). The recipient entity can then release its own connection and transaction 
resources. The reset procedure may not be applicable when only a limited part of an SMLC or BSS has suffered a 
failure, since error recovery procedures specific to individual connections and transactions may then be used. 

5.7.1 Normal Operation 

In the event of a failure at an SMLC or BSS that results in the loss of LMU connection information and location service 
information, a Reset message may be sent to the partner SMLC or BSS across the Lb interface. The message carries no 
parameters and is sent using connectionless SCCP procedures. The sending entity shall ensure that all information on 
LMU connections and location service transactions to the other entity is reinitialized to indicate no existing connections 
and transactions. 

On receiving a Reset message, the recipient SMLC or BSS shall clear all references and state information for LMU 
connections and location service transactions to the sending entity and shall release any associated resources including, 
in the case of a recipient BSS, any signaling connections or circuit connections to LMUs controlled by a sending 
SMLC. The recipient entity shall then return a Reset Acknowledge message. 

For a reset on the Lb interface where the SMLC and BSS support circuit connections to LMUs (in addition to signaling 
connections), the entity that does not control assignment of circuits shall initiate blocking procedures (Block or Circuit 
Group Block procedure as defined in 3GPP TS 48.008) for all circuits that are locally blocked on its own side. The 
initiation of blocking may occur before sending or receipt, whichever applies, of the Reset Acknowledge. 

5.7.2 Abnormal Conditions 

If an initiating SMLC or BSS receives no response to a Reset message following an O&M administered time period, it 
shall resend the Reset message. For successive no response conditions, sending shall occur a maximum of "n" times, 
where "n" is an O&M administered parameter. Following "n" unsuccessful, reset attempts, the procedure shall be 
terminated and maintenance shall be informed. 
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5.8 Perform Location Information 

The Perform Location Information procedure is applicable to the Lb interface. It enables an SMLC to be informed by 
the BSS when a target MS in the PS domain (A/Gb-mode) has changed serving cell. The procedure is only vaUd while a 
location request procedure for the target MS is ongoing. The procedure makes use of SCCP connection oriented 
signaling on the Lb interface and uses the same SCCP connection as the location request procedure for the particular 
target MS. 

The BSS initiates the procedure when a location request procedure for the target MS is ongoing in the PS domain and 
the BSS has determined that the target MS has changed cell (e.g. by reception of a BSSGP FLUSH-LL PDU). The BSS 
sends a Perform Location Information message to the SMLC. This procedure may also optionally be initiated by the 
BSS for Intra-BSC handover during positioning of a target MS in the CS domain when no BSSLAP procedure is 
ongoing. The message contains the following mandatory (M) and conditional (C) information. 

- Cell Identifier (M). 

- BSSLAP APDU (C). 

The BSSLAP APDU shall be included and include the Timing Advance value, if that value is available for the target 
MS in the new cell. 

On receiving the Perform Location Information message, the SMLC shall store the new Cell Identifier value and the 
Timing Advance value, if provided. 



6 Usage of BSSAP-LE and BSSAP on the Lb Interface 

6.1 Applicable Message Sets 

The following BSSAP-LE message sets are applicable to the Lb interface between an SMLC and BSS: 

- All DTAP-LE messages; 

All BSSMAP-LE positioning messages; 
All BSSMAP-LE information messages; 

- All BSSMAP-LE general messages. 

The following BSSMAP messages defined in 3GPP TS 48.008 are applicable to the Lb interface to support signaling to 
a Type A LMU using an SDCCH: 

- Cipher Mode Command (SMLC to BSC); 

- Cipher Mode Complete (B S C to SMLC) ; 

- Cipher Mode Reject (BSC to SMLC); 

- Classmark Update (BSC to SMLC); 

- Clear Command (SMLC to BSC); 

- Clear Complete (BSC to SMLC); 

- Clear Request (BSC to SMLC); 

- Complete Layer 3 Information (BSC to SMLC); 

- Confusion (BSC to SMLC); 

- Handover Required (BSC to SMLC); 

- Handover Required Reject (SMLC to BSC); 
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- Handover Performed (BSC to SMLC); 

- Paging (SMLC to BSC). 

The following additional BSSMAP messages defined in 3GPP TS 48.008 are applicable to the Lb interface to support 
signaling to a Type A LMU using a TCH: 

- Assignment Request (SMLC to BSC); 

- Assignment Complete (BSC to SMLC); 

- Assignment Failure (BSC to SMLC); 
Block (two way); 

Blocking Acknowledge (two way); 

Unblock (two way); 

Unblocking Ack. (two way); 

Unequipped circuit (two way). 

The following DTAP messages defined in 3GPP TS 24.008 and 3GPP TS 44.018 are applicable to the Lb interface to 
support signaling to a Type A LMU using an SDCCH: 

- RR Paging Response; 

- All MM Messages. 

The following additional CM level DTAP messages defined in 3GPP TS 24.008 are applicable to the Lb interface to 
support signaling to a Type A LMU using a TCH. 

- Call Confirmed (LMU to SMLC). 

- Connect (LMU to SMLC). 

- Connect Acknowledge (SMLC to LMU). 

- Setup (SMLC to LMU). 
Disconnect (two way). 
Release (two way). 
Release Complete (two way). 

6.2 MTP Functions 

Except where defined otherwise in the present document, MTP and M3UA/SCTP requirements on the Lb interface for 
the BSS are the same as those defined for the A interface in 3GPP TS 48.006 for the BSC. MTP and M3UA/SCTP 
requirements on the Lb interface for the SMLC are the same as those defined for the A interface in 3GPP TS 48.006 for 
the MSC. STP functions are not required in the SMLC and a single signaling link set may be used between the BSS and 
SMLC. The BSS shall be homed to a single SMLC and shall only use the Lb signaling interface for signaling 
communication with the SMLC. 

6.3 SCCP Functions 
6.3.1 General 

Except where defined otherwise in the present document, SCCP requirements on the Lb interface for the BSS are the 
same as those defined for the A interface in 3GPP TS 48.006 for the BSC. SCCP requirements on the Lb interface for 
the SMLC are the same as those defined for the A interface in 3GPP TS 48.006 for the MSC. Requirements concerning 
support of a type A LMU are the same as those in 3GPP TS 48.006 regarding support of a normal MS. In particular. 
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usage of SCCP to transfer DTAP-LE messages between a type A LMU and SMLC are the same as those regarding 
transfer of other DTAP messages. 

6.3.2 Modifications for Connectionless SCCP 

Connectionless SCCP messages and procedures are used to transfer BSSMAP-LE Connectionless Information 
messages and those BSSMAP messages applicable to the Lb interface for which connectionless SCCP transfer is 
defined in 3GPP TS 48.008. Refer to 3GPP TS 43.059 for a description of the procedures in the SMLC and BSC. SCCP 
protocol class 1 shall be used when multiple BSSMAP-LE messages are transferred containing segments of a single 
fragmented LLP or SMLCPP message. 

6.3.3 Modifications for Connection Oriented SCCP 

Use of connection oriented SCCP messages and procedures on the Lb interfaces to support signaling access to a type A 
LMU using DTAP-LE, DTAP and BSSMAP messages is the same as that defined in 3GPP TS 48.006 on the A 
interface to support access to a normal MS. 

To support positioning of a target MS, connection oriented SCCP messages and procedures using protocol class 2 shall 
be used to transfer BSSMAP-LE positioning messages and BSSMAP-LE Connection Oriented Information messages 
over the Lb interface. A separate dedicated SCCP connection shall be used to support positioning for each target MS. 
Connection establishment shall be instigated by the BSS when the positioning attempt commences. Connection release 
shall be instigated by either the BSS or SMLC when the positioning attempt has been completed or has failed. The 
SMLC is primarily responsible for ensuring release - e.g. in the event that the BSS waits for the SMLC to instigate 
release. 

Transfer of BSSMAP-LE messages using an SCCP connection to support positioning of a particular target MS is 
shown in the following figure. In particular, a BSSMAP-LE message shall be included in the data field of the SCCP 
CR and a BSSMAP-LE message may be included in the data field of an SCCP CC, CREF or RLSD message. 



BSC 



SMLC 



1. SCCP CR [BSSMAP-LE message] 



2. SCCP CREF [BSSMAP-LE message or no data] 

OR 

< 

2. SCCP CC [BSSMAP-LE message or no data] 

< 1 

3. SCCP DTI [BSSMAP-LE message] 

4. SCCP RLSD [BSSMAP-LE message or no data] 

< 

5.SCCPRLC 

OR 

4 

4. SCCP RLSD [BSSMAP-LE message or no data] 

¥ 

5. SCCP RLC 



Figure 6.3.3: SCCP Connection Oriented Signaling on Lb Interface for Positioning 

6.3.4 Contents of tine SCCP Data Field 

The contents of the SCCP data field are the same as that defined for the A interface in 3GPP TS 48.006 for MSC-BSC 
signaling. In particular, the same conventions are used to transfer and discriminate between any BSSAP and DTAP 
message contained within the SCCP data field. Since all BSSAP-LE messages applicable to the Lb interface use the 
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same encoding as for the A interface, the conventions used to discriminate a BSSMAP message are applicable to any 
BSSMAP-LE message on the Lb interface, while the conventions for a DTAP message apply to any DTAP-LE 

message. 

6.3.5 Abnormal Conditions 

If a user-out-of-service information or signalling-point-inaccessible information is received by a BSS or SMLC, no new 
attempt to establish SCCP connections towards the affected point code shall be started until the corresponding user-in- 
service information or signalling-point-accessible information is received. 

When a user-out-of-service information or signalling-point-inaccessible is received, an optional timer may be started. If 
the timer expires all the SCCP connections towards the affected point code shall be released. When the user-in-service 
or signalling-point-accessible is received, the timer is stopped. 

If an SCCP connection is released, the optional timer expires or a connection refusal is received, any dependent 
BSSAP-LE procedure between the SMLC and BSS shall be terminated and, at a BSS, any associated SCCP connection 
or location service transaction to an MSC, or any associated signaling or circuit connection to an LMU, shall be 
released using appropriate signalling procedures. 



7 (void) 



8 Use of BSSAP-LE on the Lp Interface 

8.1 Applicable Message Sets 

The following BSSAP-LE messages are applicable to the Lp interface between an SMLC and a peer SMLC. 
BSSMAP-LE Connectionless Information message. 

8.2 MTP Functions 

SS7 signaling on the Lp interface may be supported using 56 kbps or 64 kbps digital signaling channels. These may be 
supported within either El or Tl physical links. 

Two SMLCs may be connected by direct point-to-point SS7 signaling links or links may be employed via intermediate 
STPs. Alternatively, signaling transfer between two SMLCs may be supported via intermediate BSSs and/or MSCs 
using the Lb and/or Ls interfaces. Signaling requirements to support message transfer on the Lp interface via an 
intermediate Lb interface are the same as those defined elsewhere in the present document for these interfaces. This 
sub-clause defines the requirements applicable to direct SMLC-SMLC SS7 links and SS7 links from an SMLC to an 
STP. 

For El links or where ITU-T/ITU SS7 signaling is applicable, the MTP functions as specified in ITU-T 
Recommendations Q.702, Q.703, Q.704 and Q.707 are applicable. For Tl links or where ANSI SS7 signaling is 
applicable, the MTP functions as specified in ANSI Tl.lll are applicable. Only the requirements in these 
recommendations for a signaling end point are applicable. 

Where an SMLC has no signaling links to an STP, certain exceptions and modifications to normal ITU-T and ANSI 
requirements may be applied within a PLMN administration. 

It is recommended that when IP transport (via M3UA/SCTP) is used, the data link layer is implemented using Ethernet. 
A node using IP transport having interfaces connected via low bandwidth PPP links like El/Tl shall also support IP 
Header Compression [25] and the PPP extensions ML/MC-PPP [26], [27]. In this case, the negotiation of header 
compression [25] over PPP shall be performed according to [28]. 
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8.3 SCCP functions 

8.3.1 General 

For El links or where ITU-T/ITU SS7 signaling is applicable, the SCCP functions as specified in either ITU-T Blue 
Book Recommendations Q.711, Q.712, Q.713 and Q.714 or ITU White Book Recommendations Q.711, Q.712, Q.713 
and Q.714 are applicable, as amended by the exceptions and modifications defined here. For Tl links or where ANSI 
SS7 signaling is applicable, the MTP functions as specified in ANSI T1.112 are applicable, as amended by the 
exceptions and modifications defined here. For M3UA/SCTP signalling, functions as specified in 3GPP TS 29.202 [29] 
are applicable, as amended by the exceptions and modifications defined here. 

8.3.2 Allowed Exceptions to ITU-T Recommendations Q.71 1 -71 4 

Only the following SCCP messages are applicable to the Lp interface: 
Inactivity Test (IT); 

- Subsystem Allowed (SSA); 

- Subsystem Prohibited (SSP); 

- Subsystem Status Test (SST); 

- Unitdata (UDT); 

- Unitdata Service (UDTS). 

Support of only SCCP protocol classes and 1 is required. 

The SCCP called party address in a UDT may contain only the subsystem number (SSN) or a signaling point code 
(SPC) plus SSN or a global title. Use of a global title is not required for SMLC to SMLC signaling within the same 
PLMN. SSN values appHcable to the Lp interface are defined in 3GPP TS 23.003. 

8.3.3 Allowed Exceptions to ANSI Tl . 1 1 2 

Only the following SCCP messages are applicable to the Lp interface: 
Inactivity Test (IT); 

- Subsystem Allowed (SSA); 

- Subsystem Prohibited (SSP); 

- Subsystem Status Test (SST); 

- Unitdata (UDT); 

- Unitdata Service (UDTS). 

Support of only SCCP protocol classes and 1 is required. 

The SCCP called party address in a UDT may contain only the subsystem number (SSN) or a signaling point code 
(SPC) plus SSN or a global title. Use of a global title is not required for SMLC to SMLC signaling within the same 
PLMN. SSN values appHcable to the Lp interface are defined in 3GPP TS 23.003. 

8.3.4 Usage of Connectionless SCCP 

Connectionless SCCP messages and procedures shall be used to transfer BSSMAP-LE Connectionless Information 
messages. Refer to 3GPP TS 43.059 for a description of the procedures in the SMLC. SCCP protocol class 1 shall be 
used when multiple BSSMAP-LE messages are sent containing segments of a single fragmented SMLCPP message. 
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8.3.5 Usage of Connection Oriented SCCP 

Connection oriented SCCP messages and procedures are not applicable to the Lp interface. 

8.3.6 Contents of the SCCP Data Field 

The contents of the SCCP data field are shown in the following figure. 





8 


7 


6 


5 


4 


3 


2 


1 


Octet 1 























D=0 


Octet 2 


Length indicator = n 


Octet 3 

to 

Octet n+2 


BSSMAP-LE Message Contents 



Figure 8.3.6-1 : SCCP Data Field for a BSSIVIAP-LE Message 

The Discrimination Indicator is coded in bit 1 of octet one and indicates the type of the BSSAP-LE message. 



Discrmlnation Indicator 


BSSAP-LE Message Type 





BSSMAP-LE 



The length indicator is coded in one octet, and is the binary representation of the number of octets of the subsequent 
BSSMAP-LE message content. 

NOTE: The contained BSSMAP-LE message may itself contains an APDU containing either a complete LLP or 
SMLCPP message or a part of segmented SMLCPP message. 



9 Message Functional Definitions and Contents 

For each message there is, in this sub-clause, a table listing the signalling elements in their order of appearance in the 
transmitted message. 



£75/ 



3GPP TS 49.031 version 7.6.0 Release 7 



23 



ETSI TS 149 031 V7.6.0 (2008-04) 



9.1 BSSMAP-LE PERFORM LOCATION REQUEST message 

This message is sent to request a location estimate for a target MS and contains sufficient information to enable location 
according to the required QoS using any positioning method supported by the PLMN and, where necessary, MS. The 
message is also used to request LCS assistance data transfer to an MS or request deciphering keys for LCS broadcast 
assistance data. The message can be sent from the BSS to the SMLC. 

Table 9.1 : BSSMAP-LE PERFORM LOCATION REQUEST message content 



Information element 


Type/Reference 


Presence 


Format 


Length in 
octets 


Message type 


Message Type 


M 


V 


1 


Location Type 


Location Type 


M 


TLV 


3-4 


Cell Identifier 


Cell Identifier 


M 


TLV 


3-10 


Classmark Information Type 3 


Classmark Information Type 3 





TLV 


2-n 


LCS Client Type 


LCS Client Type 


C 


TLV 


3 


Chosen Channel 


Chosen Channel 





TLV 


2-n 


LCS Priority 


LCS Priority 





TLV 


3 


LCS QoS 


LCS QoS 





TLV 


6 


Requested GPS Assistance Data 


Requested GPS Assistance Data 





TLV 


3-n 


BSSLAP APDU 


APDU 


Q 


TLV 


2-n 


LCS Capability 


LCS Capability 





TLV 


3-n 


Packet IVIeasurement Report 


Packet Measurement Report 





TLV 


2-n 


Measured Cell Identity List 


Cell Identity List 





TLV 


6-n 


IMSI 


IMSI 


(Note 1 ) 


TLV 


5-10 


IMEI 


IMEI 


(Note 1 ) 


TLV 


10 


GANSS Location Type 


GANSS Location Type 


C 


TLV 


3 


Requested GANSS Assistance Data 


Requested GANSS Assistance 
Data 


Q 


TLV 


3-n 


NOTE 1 : The IMSI should be sent preferably if known. The IMEI could be sent if the IMSI is not known, or in addition to 
the IMSI for the purpose of allowing correlation between the two identities. 



9.1.1 Location Type 

This parameter defines the type of location information being requested. 

9.1.2 Cell Identifier 

This parameter gives the current cell location of the target MS. The format shall either be the cell global identification 
or the LAC plus CI form. 

9.1 .3 Classmark Information Type 3 

This parameter indicates the positioning methods supported by the MS as obtained from the MS Classmark 3 received 
earlier from the target MS. 

9.1.4 LCS Client Type 

This parameter defines the type of the originating LCS Client. It shall be included if the Location Type indicates a 
request for a location estimate and may be included in other cases to assist an SMLC to appropriately prioritize a 
location request. 

9.1.5 Chosen Channel 

This parameter defines the type of radio channel currently assigned to the target MS. 
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9.1.6 LCS Priority 

This parameter defines the priority of the location request. 

9.1.6a LCSQoS 

This parameter provides the required Quality of Service for the LCS Request. Quality of Service may include horizontal 
accuracy, vertical accuracy and allowed response time. 

9.1 .7 Requested GPS Assistance Data 

This parameter identifies the specific GPS assistance data that may be requested. 

9.1.8 BSSLAPAPDU 

This parameter provides additional measurements (e.g. timing advance and measurement report) in a BSSLAP TA 
Layer3 message for the target MS from the BSS. The measurements are contained inside a BSSLAP APDU. This 
parameter shall be included for location requests for the PS Domain in A/Gb-mode when the timing advance value is 
available in the BSS. 

9.1.9 LCS Capability 

This parameter provides information about the LCS capabilities of the target MS. This IE and the Classmark 
Information Type 3 IE are mutually exclusive. 

9.1 .1 Pacl<et Measurement Report 

This parameter provides information about the neighbour measurements that the target MS has performed for a 
positioning request in the PS domain. 

9.1 .1 1 Measured Cell Identity List 

This parameter provides information about the cell identities relative to the packet measurement report IE. 

9.1.12 IMSI 

This parameter identifies the IMSI of the target Mobile Station. 

9.1.13 IMEI 

This parameter identifies the IMEI of the target Mobile Station. 

9.1.14 G ANSS Location Type 

This parameter identifies the GANSS Location type. 

9.1.15 Requested GANSS Assistance Data 

This parameter identifies the specific GNSS (e.g. Galileo) assistance data that may be requested. 

9.2 BSSMAP-LE PERFORM LOCATION RESPONSE message 

This message is sent in response to a BSSMAP-LE Perform Location Request to return a successful location estimate 
for a target MS or to indicate some failure in obtaining this. The message is also sent in response to a BSSMAP-LE 
Perform Location Request to return deciphering keys or an indication that LCS assistance data has been successfully 
delivered to an MS. The message can be sent from the SMLC to the BSS. 
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Table 9.2: BSSMAP-LE PERFORM LOCATION RESPONSE message content 



Information element 


Type/Reference 


Presence 


Format 


Length in 
octets 


Message type 


Message Type 


M 


V 


1 


Location Estimate 


Geographic Location 


C 


TLV 


2-22 


Positioning Data 


Positioning Data 





TLV 


2-n 


Deciphering Keys 


Deciphering Keys 





TLV 


17 


LCS Cause 


LOS Cause 





TLV 


3-4 


Velocity Data 


Velocity Data 





TLV 


6-9 


GANSS Positioning Data 


GANSS Positioning Data 





TLV 


3-n 



9.2.1 Location Estimate 

This parameter provides a location estimate for the target MS in the case of a successful location attempt. 

9.2.2 Positioning Data 

This parameter provides additional information for the positioning attempt from the SMLC. 

9.2.3 Deciplnering Keys 

This parameter provides two deciphering keys that can be used to decode LCS broadcast assitance data by the MS. The 
SMLC shall provide the current deciphering key for the MS's present location. The SMLC shall also provide the next 
deciphering key apphcable after the current deciphering key . 

9.2.4 LCS Cause 

The LCS Cause is included if and only if a requested location estimate was not successfully obtained (e.g. location 
estimate not available), requested deciphering keys were not successfully returned or requested LCS assistance data was 
not successfully transferred to the MS. The parameter provides the reason for the failure. If the LCS Cause is included, 
the Location Estimate and Deciphering Key shall not be included. 

9.2.5 Velocity Data 

This parameter gives an estimate of the velocity of an MS and for certain encodings the uncertainty of the estimate. The 
estimate is expressed in terms of any of the velocity descriptions defined by 3GPP TS 23.032 and is composed of the 
velocity type plus the encoding of that type. 

9.2.6 GANSS Positioning Data 

This parameter provides additional information for the positioning attempt in case where GANSS has been used. It 
describes the nature of GANSS used. 

9.3 BSSMAP-LE PERFORM LOCATION ABORT message 

This message is sent by the instigator of a location request to abort the positioning attempt or the request for assistance 
data or deciphering keys. This message can be sent from the BSS to the SMLC. 

Table 9.3: BSSMAP-LE PERFORM LOCATION ABORT message content 



Information element 


Type/Reference 


Presence 


Format 


Length in 
octets 


Message type 


Message Type 


M 


V 


1 


LCS Cause 


LCS Cause 


M 


TLV 


3-4 
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9.3.1 LCS Cause 

The LCS Cause provides the reason for the aborting the location attempt. 



9.4 



(void) 



9.5 



9.6 



9.7 



(void) 
(void) 
(void) 



9.8 BSSIVIAP-LE CONNECTION ORIENTED INFORMATION 
message 

This message is sent in association with an existing signaling connection between an SMLC and another entity to 
transfer information between the SMLC and other entity belonging to a higher level protocol. The message can be sent 
from a BSS to an SMLC and from an SMLC to a BSS. 

Table 9.8: BSSMAP-LE CONNECTION ORIENTED INFORMATION message content 



Information element 


Type/Reference 


Presence 


Format 


Length in 
octets 


Message type 


Message Type 


M 


V 


1 


BSSLAP APDU 


APDU 


M 


TLV 


3-n 


Segmentation 


Segmentation 


C 


TLV 


3 



9.8.1 BSSLAP APDU 

This parameter contains a BSSLAP message. 

9.8.2 Segmentation 

This parameter contains segmentation information for a segmented APDU. The parameter shall not include message 
information. The parameter shall be included if and only if the BSSLAP APDU is segmented. 

9.9 BSSMAP-LE CONNECTIONLESS INFORMATION 
message 

This message conveys signaling information associated with a higher protocol level between an SMLC and another 
entity when there is no existing signaling connection association. The message can be sent from a BSC to an SMLC, 
from an SMLC to a BSC and from an SMLC to another SMLC. 
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Table 9.9: BSSMAP-LE CONNECTIONLESS INFORMATION message content 



Information element 


Type/Reference 


Presence 


Format 


Length in 
octets 


Message type 


Message Type 


M 


V 


1 


Source Identity 


Network Element Identity 


M 


TLV 


3-n 


Destination Identity 


Network Element Identity 


M 


TLV 


3-n 


APDU 


APDU 





TLV 


3-n 


Segmentation 


Segmentation 


C 


TLV 


5 


Return Error Request 


Return Error Request 





TLV 


2 


Return Error Cause 


Return Error Cause 





TLV 


3 



9.9.1 Source Identity 

This parameter identifies the original source of the message. The original source can either be an SMLC or a Type B 
LMU. The source is identified by association with either a location area or a cell site. 

9.9.2 Destination Identity 

This parameter identifies the final destination of the message. The final destination can either be an SMLC or a Type B 
LMU. The destination is identified by association with either a location area or a cell site. 

9.9.3 APDU 

This parameter contains an embedded APDU. For information transfer between an SMLC and Type B LMU this shall 
be an LLP APDU. For information transfer between two peer SMLCs, this shall be an SMLCPP APDU. 

9.9.4 Segmentation 

This parameter contains segmentation and message information for a segmented APDU. The parameter shall be 
included if and only if a segmented APDU is present. 

9.9.5 Return Error Request 

This parameter may be included to request an error response if BSSMAP-LE message cannot be delivered successfully 
to its final destination. This parameter shall not be included if the Return Error cause is present. 

9.9.6 Return Error Cause 

This parameter indicates an error response for a BSSMAP-LE connectionless information message that could not be 
delivered to its final destination. The APDU should be present and the same as the APDU in the original undelivered 
message. The source and destination identities shall be included and the same as the destination and source identities, 
respectively, in the original undelivered message. 



9.10 BSSMAP-LE RESET message 



This message is sent to indicate a failure in the sending entity with loss of memory of LMU connections and location 
service transactions that were established or were being established. The message may be sent from an SMLC to a BSS 
and from a BSS to an SMLC. 

This message is sent as a connectionless SCCP message. 
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Table 9.10: BSSMAP-LE RESET message content 



Information element 


Type/Reference 


Presence 


Format 


Length In 
octets 


Message type 


Message Type 


M 


V 


1 


Cause 


Cause 


M 


TLV 


3-4 



9.1 1 BSSMAP-LE RESET ACKNOWLEDGE message 

This message is sent in response to a Reset message to indicate that references and resources associated with LMU 
connections and location service transactions towards the entity sending the Reset have been released. The message 
may be sent from an SMLC to a BSS and from a BSS to an SMLC. 

This message is sent as a connectionless SCCP message. 

Table 9.11 : BSSMAP-LE RESET ACKNOWLEDGE message content 



Information element 


Type/Reference 


Presence 


Format 


Length In 
octets 


Message type 


Message Type 


M 


V 


1 



9.12 BSSMAP-LE PERFORM LOCATION INFORMATION 
message 

This message is sent from the BSS to the SMLC to notify the SMLC that the target MS is now located in a new cell. 
Table 9.12: BSSMAP-LE PERFORM LOCATION INFORMATION message content 



Information element 


Type/Reference 


Presence 


Format 


Length In 
octets 


Message type 


Message Type 


M 


V 


1 


Cell Identifier 


Cell Identifier 


M 


TLV 


3-10 


BSSLAP APDU 


APDU 





TLV 


2-n 



9.12.1 Cellldentifier 

This parameter gives the new cell location of the target MS. The format shall either be the cell global identification or 
the LAC plus CI form. 

9.12.2 BSSLAP APDU 

This parameter provides additional measurements (timing advance) in a BSSLAP TA LayerS message for the target MS 
from the BSS. The measurements are contained inside a BSSLAP APDU. 



1 Message format and information element coding 

This sub-clause specifies the coding of the Information Elements used by the BSS AP-LE protocol. The spare bits in the 
coding of an IE shall be set to zero by the sender and shall be ignored by the receiver. 

All unassigned codes (whether omitted or explicitely Unassigned in the text) shall be treated as unknown. 

The following conventions are assumed for the sequence of transmission of bits and bytes: 

Each bit position is marked as 1 to 8. Bit 1 is the least significant bit and is transmitted first. 
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In an element octets are identified by number, octet 1 is transmitted first, then octet 2 etc. 

When a field extends over more than one octet, the order of bit values progressively decreases as the octet number 
increases. The least significant bit of the field is represented by the lowest numbered bit of the highest numbered octet 
of the field. 

For variable length elements a length indicator is included, this indicates the number of octets following in the 
element. 

All fields within Information Elements are mandatory unless otherwise specified. The Information Element 
Identifier shall always be included. 

All spare bits are set to 0. 

For any information element of format TLV, the length indicator octet, as in 3GPP TS 48.008, defines the number of 
octets in the information element that follow the length indicator octet. 



10.1 Message type 

Message type uniquely identifies the message being sent. It is a single octet element, mandatory in all messages. 

Table 10.1 : Message type information element 



Category 



87654321 



Message Type 



POSITIONING MESSAGES 



Reserved (NOTE) 



INFORMATION MESSAGES 



GENERAL MESSAGES 



00000000 Reserved. 

10 10 11 BSSMAP-LE PERFORM LOCATION REQUEST 

10 110 1 BSSMAP-LE PERFORM LOCATION RESPONSE 

10 1110 BSSMAP-LE PERFORM LOCATION ABORT 

10 1111 BSSMAP-LE PERFORM LOCATION INFORMATION 

1 Reserved (note) 

1 Reserved (note) 

1 1 Reserved (note) 

1 Reserved (note) 

10 10 10 BSSMAP-LE CONNECTION ORIENTED INFORMATION 

1110 10 BSSMAP-LE CONNECTIONLESS INFORMATION 



110 RESET 

00 11000 1 RESET ACKNOWLEDGE 
NOTE: These values of the codepoints shall not be used as they were used in an earlier version of the 
protocol. 



10.2 Information Element Identifiers 

The next list shows the coding of the Information Element Identifiers used in the present document. 

Table 10.2: Information Element Identifier coding 



87654321 


Information element 


Reference 


00111110 


LCS QoS 


10.16 


01000011 


LCS Priority 


10.15 


01000100 


Location Type 


10.18 


10000010 


GANSS Location Type 


10.33 


01000101 


Geographic Location 


10.9 


01000110 


Positioning Data 


10.20 


1 000001 1 


GANSS Positioning Data 


10.32 
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01010101 


Velocity Data 


10.30 


01000111 


LCS Cause 


10.13 


01001000 


LCS Client Type 


10.14 


0100100 1 


APDU 


10.3 


010010 10 


Network Element Identity 


10.19 


01001011 


Requested GPS Assistance Data 


10.10 


01000001 


Requested GANSS Assistance Data 


10.31 


01001100 


Deciphering Keys 


10.8 


0100110 1 


Return Error Request 


10.21 


01001110 


Return Error Cause 


10.22 


01001111 


Segmentation 


10.24 


000100 11 


Classmark Information Type 3 


10.7 


00000100 


Cause 


10.4 


0000010 1 


Cell Identifier 


10.5 


00 100001 


Chosen Channel 


10.6 


00000000 


IMS! 


10.11 


00000001 


Reserved (note) 




00000010 


Reserved (note) 




0000001 1 


Reserved (note) 




00000100 


Reserved (note) 




01010000 


LCS Capability 


10.26 


01010001 


Packet IVIeasurement Report 


10.27 


010100 10 


Cell Identity List 


10.28 


10000000 


IMEI 


10.29 


NOTE: These values of the codepoints shall not be used as they were used in an 
earlier version of the protocol. 



10.3 APDU 

This is a variable length information element that conveys an embedded message or message segment associated with a 
higher level protocol. 





8 7 


|6|5|4|3|2|1| 


Octet 1 


IE! 


Octet 2-3 


Length indicator 


Octet 4 


Spare 


Protocol ID 


Octet 5 

to 
Octet n 


The rest of the information element contains a message or 
message segment whose content and encoding are defined 
according to the protocol ID. 



Figure 10.3.1: APDU IE 



Length Indicator (octets 2-3). 



The most significant bit is bit 8 of Octet 2, and the least significant bit is bit 1 in Octet 3. The length indicator defines 
the total number of octets after length indicator. 

Protocol ID (bits 7-1 of octet 4). 



0000000 


reserved 


0000001 


BSSLAP 


0000010 


LLP 


0000011 


SMLCPP 



Embedded Message (octets 5-n) 



BSSLAP 



the embedded message is as defined in 3GPP TS 48.071 



LLP 



the embedded message contains a Facility Information Element as defined in 3GPP TS 44.071 
excluding the Facility lEI and length of Facility IE! octets defined in 3GPP TS 44.071 . 



SIVILCPP 



the embedded message is as defined in 3GPP TS 48.031 
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10.4 Cause 

This is a variable length information element indicating the reason for sending a Reset message. 



Octet 1 
Octet 2 
Octet 3 



8 7 6 


1 5 1 4 1 


3 1 2 1 1 1 


lEI 


Length indicator 


The rest of the information element is coded 
the Cause IE defined in 3GPP TS 48.008. 


as the value part of 



Figure 10.4.1 : Cause IE 



10.5 Cell Identifier 



This is a variable length information element identifying a particular cell. 



Octet 1 
Octet 2 
Octet 3 



8 7 


6 1 5 1 4 1 


3 


2 1 1 1 


lEI 


Length indicator 


The rest of the information element is coded as the value part of 
the Cell Identifier IE defined in 3GPP TS 48.008. 



Figure 10.5.1 : Cell Identifier IE 



10.6 Chosen Channel 



This information element identifiers a type of radio interface channel. 



Octet 1 
Octet 2 
Octet 3 



8 


7 1 6 1 5 1 4 1 


3 1 


2 1 1 1 


lEI 


Length indicator 


The rest of the information element is coded as the value part of 
the Chosen Channel IE defined in 3GPP TS 48.008. 



Figure 10.6.1 : Chosen Channel IE 



1 0.7 Classmark Information Type 3 

This information element contains classmark information for a target MS obtained from the MS Classmark 3 defined in 
3GPP TS 24.008. 



Octet 1 
Octet 2 
Octet 3 



lEI 



Length indicator 



The rest of the information element is coded as the value part of 
the Classmark Information Type 3 IE defined in 3GPP TS 48.008. 



Figure 10.7.1 : Classmark Information Type 3 IE 
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10.8 Deciphering Keys 



This information element defines the deciphering keys which should used by the MS to decode LCS broadcast 
assistance data. The parameter includes following data fields. All fields shall be included: 





8 


7 


6 1 5 1 4 1 3 


2 1 1 1 


Octet 1 


lEI 


Octet 2 


Length indicator 


Octet 3 


spare 


Ciphering 
Key Flag 


Octet 4 
Octet 10 


Current Deciphering Key Value 


Octet 11 
Octet 17 


Next Deciphering Key Value 



Figure 10.8.1: Deciphering Keys IE 



Ciphering Key Flag (octet 3) 



This flag indicates the current Ciphering Key Flag used in the LCS assistance data broadcast messages in the location 
area. 

Current Deciphering Key Value (octet 4 - 10) 

Current Deciphering Key contains the 56 bit deciphering key that is currently in use in location area for deciphering the 
LCS assistance data broadcast messages. 

Next Deciphering Key (octet 11 - 17) 

Next Deciphering Key contains the 56 bit deciphering key that will be used next in location area for deciphering the 
LCS assistance data broadcast messages. 



10.9 Geographic Location 



8 7 


6 1 5 1 4 1 


3 1 


2 1 1 1 


lEI 


Length indicator 


The rest of the information element contains an octet 
identical to that for Geographical Information defined 
23.032.. 


sequence 
in3GPPTS 



This is a variable length information element providing an estimate of a geographic location. 

Octet 1 
Octet 2 
Octet 3 

to 
Octet n 

Figure 10.9.1: Geographic Location IE 

Geographical Information (octet 3 to n) 

This parameter gives an estimate of the location of an MS in universal coordinates and for certain shapes the accuracy 
of the estimate. The estimate is expressed in terms of the geographical shapes defined by 3GPP TS 23.032. and is 
composed of the type of shape plus the encoding of the shape itself. Any type of shape defined in 3GPP TS 23.032 can 
be filled in in the Location Estimate parameter. 

10.10 Requested GPS Assistance Data 

This is a variable length information element identifying the GPS assistance data requested for an MS. 
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Octet 3 

bit A 

0: 

1: 

bitB 

0: 

1: 

bite 

0: 

1: 

bitD 

0: 

1: 

bitE 

0: 

1: 

bitF 

0: 

1: 

bitG 

0: 

1: 

bitH 

0: 

1: 

bit I 

0: 

1: 

bit J 

0: 

1: 





8 


7 


6 


5 


4 


3 


2 


1 


Octet 1 


lEI 


Octet 2 


Length indicator 


Octet 3 


H 


G 


F 


E 


D 


C 


B 


A 


Octet 4 


P 





N 


M 


L 


K 


J 


1 


Octet 5 

to 
Octet 
8+2n 


Satellite related data 



Figure 10.10.1 : Requested GPS Assistance Data IE 



Almanac 

Almanac is not requested 

Almanac is requested 

UTC Model 

UTC Model is not requested 

UTC Model is requested 

Ionospheric Model 

Ionospheric Model is not requested 

Ionospheric Model is requested 

Navigation Model 

Navigation Model is not requested - octets 5 to 8+2n are not present 

Navigation Model is requested - octets 5 to 8+2n are present 

DGPS Corrections 

DGPS Corrections are not requested 

DGPS Corrections are requested 

Reference Location 

Reference Location is not requested 

Reference Location is requested 

Reference Time 

Reference Time is not requested 

Reference Time is requested 

Acquisition Assistance 

Acquisition Assistance is not requested 

Acquisition Assistance is requested 

Real-Time Integrity 

Real-Time Integrity is not requested 

Real-Time Integrity is requested 

Ephemeris Extension 

Ephemeris Extension is not requested 

Ephemeris Extension is requested 



bit K Ephemeris Extension Check 

0: Ephemeris Extension Check is not requested 

1 : Ephemeris Extension Check is requested 

bits L through P are Spare bits 

At least one of bits A, B, C, D, E, F, G, H or I, J or K, shall be set to the value "1". 

Bits D, J and K are mutually exclusive, only one of these can be set to one at the same time. 
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8 7 


6 


5 4 3 2 


1 


Octet 5 


GPS Week 


Spare 


Octet 6 


GPS Week 

1 

NSAT 

Spare 


Octet 7 


GPS Toe 


Octet 8 


NSAT 


T-Toe limit 




Octet 9 


spare | 


SatID 1 




Octet 10 


I0DE1 






Octet 7+2n 


spare 


SatID n 




Octet 8+2n 


lODEn 



Figure 10.10.2: Coding of Satellite Related Data 

GPS Week (bits 7-8 octet 5 and octet 6) 

This field contains a 10 bit binary representation of the GPS Week of the assistance currently held by the MS. The most 
significant bit of the GPS Week is bit 8 in octet 5 and the least significant bit is bit 1 in octet 6. 

GPS_Toe (octet 7) 

This field contains a binary representation of the GPS time of ephemeris in hours of the newest ephemeris set contained 
in handset memory (range 0-167). 

NSAT (octet 8, bits 5-8) 

This field contains a binary representation of the number of satellites to be considered for the current GPS assistance 
request. If the MS has no ephemeris data, this field shall be set to zero. If the MS has ephemeris data whose age exceeds 
the T-Toe limit, this field may be set to zero. If the SMLC receives a zero value for this field, it shall ignore the GPS 
Week and GPS_Toe fields and assume that the MS has no ephemeris data. 

T-Toe limit (octet 8, bits 1-4) 

This field contains a binary representation of the ephemeris age tolerance of the MS to the network in hours (range 0- 
10). 

SatID X (x = 1,2, ... n) (octet 7 + 2x, bits 1-6) 

This field is present only if NSAT exceeds zero and contains a binary representation of the identity of a satellite for 
which the assistance request is applicable. The number of satellite fields is indicated in the field NSAT. 

lODE X (x = 1,2, ... n) (octet 8 + 2x) 

This field is present only if NSAT exceeds zero and contains a binary representation of the Issue of Data Ephemeris 
held in the MS, which identifies the sequence number for the satellite x (x = 1, 2, ..., n). The SMLC shall derive the 
issue date and time for the lODE of each satellite x from the GPS Week and GPS_Toe fields (e.g. when a particular 
lODE value for a satellite x was issued more than once within the period of T-Toe limit). 

GPS Extended Ephemeris 

This octet shall be present when the GPS Ephemeris Extension bit is set to '1' and absent otherwise. 



Octet 5 



8 


7 


6 


1 5 1 4 1 


3 


2 


1 1 


Validity Hours 



Figure 10.10.2a: Coding of Information Extension for Ephemeris Extension (conditional) 

Validity Hours indicate the validity time for which the Ephemeris Extension should be valid in multiples of four hours. 
GPS Ephemeris Extension Check 

These octets shall be present when the GPS Ephemeris Extension Check bit is set to '1' and absent otherwise. 
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Octet 5 

Octet 6 
Octet 7 



8 7 6 5 


4 3 2 1 


GPS Ephemeris Extension Begin 
Weel< 


GPS Ephemeris Extension End 
Week 


GPS Epiiemeris Extension Begin TOW 


GPS Ephemeris Extension End TOW 



Figure 10.10.2b: Coding of Information Extension for Ephemeris Extension Check (conditional) 

These octets define the time duration of the Ephemeris Extension held by the MS. 

The GPS Ephemeris extension Week (Begin and End) is the defined as the GPS Week modulo 4. 

The GPS Ephemeris extension TOW (Begin and End) is represented in hours into the GPS week. 

10.11 IMSI 

This information element identifies the International Mobile Subscriber Identity of the target MS (see 3GPP TS 23.003 
[10a]). 





8 7 6 5 4 3 2 1 


Octet 1 


IE! 


Octet 2 


Length indicator 


Octets 3-n 


IIVISI coded as the value part of the Mobile Identity IE defined in 
3GPPTS 24.008 (NOTE 1) 




NOTE 1 : The Type of identity f\e\6 in the Mobile Identity IE shall 
be ignored by the receiver. 



Figure 10.11.1: IMSI IE 



10.12 (void) 

10.13 LCS Cause 

The LCS Cause parameter is of variable length IE and provides the reason for an unsuccessful location request. 



Octet 1 
Octet 2 
Octet 3 
Octet 4 



8 



1 



lEI 



Length indicator 



Cause value 



Diagnostic value (note) 



NOTE: The inclusion of this octet depends on the cause value. 

Figure 10.13.1 : LCS Cause IE 
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Table 10.13.1 : Cause value 



LCS Cause value (octet 3) 


Bits 




87654321 




00000000 


Unspecified 


00000001 


System Failure 


00000010 


Protocol Error 


0000001 1 


Data missing in position request 


00000100 


Unexpected data value in position request 


00000101 


Position method failure 


000001 10 


Target MS Unreachable 


000001 1 1 


Location request aborted 


00001000 


Facility not supported 


00001001 


Inter-BSC Handover Ongoing 


00001010 


Intra-BSC Handover Complete 


0000101 1 


Congestion 


00001 100 


Inter NSE cell change 


00001 1 01 


Routing Area Update 


00001 1 10 


PTMSI reallocation 


00001 1 1 1 


Suspension of GPRS services 


00010000 




to 


unspecified in this version of the protocol 


11111111 





Diagnostic value (octet 4): 

this octet may be included if the cause value indicates "position method failure", the binary encoding of this octet 
shall encode the same set of values as defined for the PositionMethodFailure-Diagnostic in 3GPP TS 29.002. 
Values outside those defined in 3GPP TS 29.002 shall be ignored by a receiver. 



10.14 LCS Client Type 

This information element identifies the type of LCS Client. 



8 


7 1 6 1 5 1 4 1 3 1 2 


1 1 


lEI 


Length indicator 


Client Category Client Subtype 



Octet 1 
Octet 2 
Octet 3 



Figure 10.14.1 : LCS Client Type IE 

The client category (bits 8-5 of octet 3) and the client subtype (bits 4-1 of octet 3) are coded as follows. 
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Client Category 


Client Subtype 


Explanation 


0000 




Value Added Client 




0000 


unspecified 




all values 


reserved 


0010 




PLIVIN operator 




0000 


unspecified 




0001 


broadcast service 




0010 


O&M 




0011 


anonymous statistics 




0100 


Target MS service support (note 1 ) 




other values 


reserved 

note 1 : includes a CAMEL phase 3 LCS 

client 


0011 




Emergency services 




0000 


unspecified 




other values 


reserved 


0100 




Lawful Intercept services 




0000 


unspecified 




other values 


reserved 


0101 -1111 


all values 


reserved 



10.15 LCS Priority 



This information element defines the priority level of a location request. 



Octet 1 
Octet 2 
Octet 3 



8 


7 


1 6 


1 5 1 4 1 3 


1 2 1 1 1 


IE! 


Length indicator 


This octet 


is 


coded as 


the LCS-Priority octet in 


3GPP TS 29.002. 



Figure 10.15.1 : LCS Priority IE 



10.16 LCSQoS 

This information element defines the Quality of Service for a location request. 



Octet 1 
Octet 2 
Octet 3 
Octet 4 
Octet 5 
Octet 6 



8 7 


6 1 5 1 4 1 3 


1 2 


1 1 1 


IE! 


Length indicator 




spare 


1 VEL 


1 VERT 1 


HA 


Horizontal Accuracy 


VA 


Vertical Accuracy 


RT 


spare 







Figure 10.16.1 : LCS QoS IE 



Octet 3 



bit 1 VERT = vertical coordinate indicator 
0: vertical coordinate not requested 
1 : vertical coordinate is requested 

bit 2 VEL = Velocity Requested 

0: do not report velocity 

1 : report velocity if available 

Octet 4 
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bit 8 HA = horizontal accuracy indicator 

0: Horizontal Accuracy is not specified 
1 : Horizontal Accuracy is specified 

bits 7-1 Horizontal Accuracy: 

spare (set all zeroes) if HA=0 

set to 7 bit uncertainty code in 3GPP TS 23.032 if HA=1 

Octet 5 - applicable only if VERT = 1 

bit 8 VA = vertical accuracy indicator 

0: Vertical Accuracy is not specified 
1 : Vertical Accuracy is specified 

bits 7-1 Vertical Accuracy: 

spare (set all zeroes) if VA=0 

set to 7 bit uncertainty altitude code in 3GPP TS 23.032 if VA=1 

Octet 6 

bits 8-7 RT = response time category 



00 
01 
10 

11: 



Response Time is not specified 
Low Delay 
Delay Tolerant 
reserved 



bits 6-1 spare 

10.17 (void) 

10.18 Location Type 

This is a variable length information element defining the type of location information being requested. 



Octet 1 
Octet 2 
Octet 3 
Octet 4 



lEI 



Length indicator 



Location Information 



Positioning IVIetiiod 



Figure 10.18.1: Location Type IE 



Coding of location information (octet 3): 

00000000 current geographic location 

00000001 location assistance information for the target MS 

00000010 deciphering keys for broadcast assistance data for the target MS 
all other values are reserved 

Positioning Method (octet 4) 

This octet shall be included if the location information in octet 3 indicates "location assistance information for the target 
MS" or "deciphering keys for broadcast assistance data for the target MS" and shall be omitted otherwise. 

00000000 reserved 

00000001 Mobile Assisted E-OTD 

00000010 Mobile Based E-OTD 

00000011 Assisted GPS 

00000 1 00 Assisted G ANS S 

00000101 Assisted GPS and Assisted GANSS 

all other values are reserved 
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if Positionning Method (octet 4) is equal to 00000100 or 00000101 then, the GANSS definition is provided in the 
GANSS Location Type. If the GANSS Location Type is missing it means that all the satellite systems included in 
GANSS are refered. 



10.19 Network Element Identity 



This is a variable length information element identifying a network element, by association with either a designated cell 
site or a designated location area. 



Octet 1 
Octet 2 
Octet 3 
Octet 4 

to 
Octet n 



Figure 10.19.1: Network Element Identity IE 

Identity Discriminator (bits 4-1 of octet 3) 



8 


7|6|5|4|3|2|1 1 


lEI 


Length indicator 


spare Identity Discrminator 


Network Element Identification 



0000 
0001 
0100 
0101 
Olio 



Identification using the MCC + MNC +LAC + CI as defined in 3GPP TS 23.003 
Identification using LAC + CI as defined in 3GPP TS 23.003 
Identification using the MCC + MNC + LAC as defined in 3GPP TS 23.003 
Identification using the LAC as defined in 3GPP TS 23.003 
Identification using LMU ID as defined below 



All other values are reserved. 



Octet 4 

to 
Octet 10 



8 


7 


6 1 5 1 4 1 3 


2 


1 1 


IVICC+MNC+LAC+CI 



Figure 10.19.2: Coding of Network Element Identification 
using the MCC+MNC+LAC+CI 

Octets 4 to 10 are coded as the Cell Identification of the Cell Identifier IE for Cell identification discriminator = 0000 
defined in 3GPP TS 48.008. 

Octet 4 

to 
Octet 7 

Figure 10.19.3: Coding of Network Element Identification using the LAC + CI 

Octets 4 to 7 are coded as the Cell Identification of the Cell Identifier IE for Cell identification discriminator = 0001 
defined in 3GPP TS 48.008. 



8 


7 


6 


5 1 4 


3 


2 


1 1 


LAC + CI 





8 


7 


6 


5 


4 


3 


2 


1 


Octet 4 

to 
Octet 6 


MCC+ MNC 


Octet 7 

to 
Octet 8 


LAC 



Figure 10.19.4: Coding of Network Element Identification 
using the MCC + MNC + LAC 

Octets 4 to 8 are coded as the corresponding octets in the Cell Identification of the Cell Identifier List IE for Cell 
identification discriminator = 0100 defined in 3GPP TS 48.008. 
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8 


7 


6 


5 4 


3 


2 


1 


Octet 4 


LAC 


Octet 5 


LAC - continued 



Figure 10.19.5: Coding of Networit Element Identification using the LAC 

Octets 4 to 5 are coded as the corresponding octets in the Cell Identification of the Cell Identifier List IE for Cell 
identification discriminator = 0101 defined in 3GPP TS 48.008. 

Octet 4 

Octet n 

Figure 10.19.6: Coding of Network Element Identification using the LMU ID 

Octets 4 and possible additional octets are coded as one to six octets of unformatted data. The maximum allowed length 
for the LMU ID is 6 (in this case octet 4-9 carry the LMU ID). This type of Network Element Identity is a BSS 
allocated address for an LMU. It shall not be used for addressing an SMLC and shall not be used when the Network 
Element Identity is sent to the core network (i.e. one of the other choices above shall be used in such a case). 



8 


7 


6 1 5 1 4 1 3 


2 


1 1 


LMU ID 


LMU ID - continued 


LMU ID - continued 



10.20 Positioning Data 



This is a variable length information element providing positioning data associated with a successful or unsuccessful 
location attempt for a target MS. 



Octet 1 
Octet 2 
Octet 3 
Octets 4 to 
4+m-1 



Octets 4+nm-m 
to 4+nm-1 



8 


7|6|5|4|3|2|1| 


lEI 


Length indicator 


spare Positioning Data Discriminator 


Positioning Method 1 




Positioning Method n 



Figure 10.20.1: Positioning Data IE 



The positioning data discrminator (bits 4-1 of octet 3) defines the type of data and number of octets m provided for each 
positioning method: 

0000 indicate usage of each positioning method that was attempted either successfully or 

unsuccessfully; 1 octet of data is provided for each positioning method included 
all other values are reserved. 

Coding of the positioning method octets for positioning data discriminator = 0000: 

Octet X I positioning method | usage | 
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Coding of positioning method (bits 8-4): 



00000 
00001 
00010 
00011 
00100 
00101 
00110 
00111 
01000 
01001 
01010 
01011 
01100 

01101 

to 

01111 

10000 
to 

mil 



Timing Advance 
Reserved (Note) 
Reserved (Note) 
Mobile Assisted E-OTD 
Mobile Based E-OTD 
Mobile Assisted GPS 
Mobile Based GPS 
Conventional GPS 
U-TDOA 

Reserved for UTRAN use only 
Reserved for UTRAN use only 
Reserved for UTRAN use only 
Cell ID 



reserved for GSM 



reserved for network specific positioning methods 



Coding of usage (bits 3-1) 



000 
001 
010 
Oil 
100 



Attempted unsuccessfully due to failure or interruption 

Attempted successfully: results not used to generate location 

Attempted successfully: results used to verify but not generate location 

Attempted successfully: results used to generate location 

Attempted successfully: case where MS supports multiple mobile based positioning methods and 

the actual method or methods used by the MS cannot be determined 



NOTE: These values of the codepoints shall not be used as they were used in an earlier version of the protocol. 



10.21 Return Error Request 



The Return Error Request parameter indicates a request from the source of a BSSMAP-LE connectionless information 
message for an error response if the message cannot be delivered to its final destination. 





8 


7 


6 


1 5 1 4 1 


3 


2 


1 


Octet 1 


lEI 


Octet 2 


Length indicator 


Octet 3 


Return Error Type 



Figure 10.21.1: Return Error Request IE 

Coding of Return Error Type (octet 3): 

00000000 Return an unsegmented APDU or the first segment of a segmented APDU; no Return Error shall 

be sent if no APDU was received or if a subsequent segment of a segmented APDU was received 



00000001 

to 

11111111 



Reserved for future use 



1 0.22 Return Error Cause 

The Return Error Cause parameter provides the reason for unsuccessful delivery of a BSSMAP-LE Connectionless 
Information message to its final destination. 
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8 


7 


6 


5 4 


3 


2 


1 


Octet 1 


lEI 


Octet 2 


Length indicator 


Octet 3 


Cause value 



Figure 10.22.1 : Return Error Cause IE 
Table 10.22.1 : Cause value 



Cause value (octet 3) 


Bits 




87654321 




00000000 


Unspecified 


00000001 


System Failure 


00000010 


Protocol Error 


0000001 1 


Destination unknown 


00000100 


Destination unreachable 


00000101 


Congestion 


000001 10 




to 


unspecified in this version of the protocol 


11111111 





10.23 (void) 

10.24 Segmentation 

This is a variable length information element that carries information for a segmented APDU. 



Octet 1 

Octet 2 

Octets 3-n 



8 


7 1 6 1 5 1 4 1 3 1 2 


1 1 


lEI 


Length indicator 


Segmentation and IVIessage Information 



Figure 10.24.1: Segmentation IE 



There are two options for the coding of the Segmentation and Message Information portion; 1 octet containing 
segmentation information only and 3 octets containing segmentation and message information. 

Encoding of Segmentation Information: 

Octet 3 __ 

Figure 10.24.2: Segmentation Information 

Encoding of Segmentation and Message Information: 



8 7 6 


5 


4 3 2 1 


Spare 


S 


Segment Number 





8 7 6 


5 


4 3 2 1 


Octet 3 


Spare 


S 


Segment Number 


Octet 4-5 


IVIessage ID 



Figure 10.24.3: Segmentation and Message Information 

S (Segmentation Bit, bit 5 of octet 3) 

final segment of a segmented message 

1 non-final segment of a segmented message 
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Segment Number (bits 4-1 of octet 3) 

This field contains a 4 bit binary representation of the segment number. The first segment has the value '0000', the next 
'000 r, and so on. 

Message ID (octets 4 and 5) 

This field contains a 16 bit binary representation of the message identity, i.e. values 0-65535 are possible. 

This field is used to identify to which messages different segments belong to. 

10.25 (void) 

10.26 LCS Capability 

This is a variable length information element that carries the LCS capabilities for the target MS. 



Octet 1 

Octet 2 

Octet 3-n 



8 



1 



lEI 



Length indicator 



Rest of element coded as the value part of the LCS Capability 

information element in 3GPP TS 48.018, not including 
3GPP TS 48.018 lEI and length indicator. 



Figure 10.26.1: LCS Capability IE 



10.27 Packet IVIeasurement Report 

This is a variable length information element that carries the packet measurement report for the target MS. 





8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2 


Length indicator 


Octet 3-n 


Rest of element coded as the Packet Measurement Report 
message or the Packet Enhanced Measurement Report message 

starting with the 6-bit MESSAGE_TYPE (see clause 1 1 in 

3GPP TS 44.060) and ending with the Non-distribution contents 

(i.e. the RLC/MAC padding bits are not included). The end of the 

message is padded with 0-bits to the nearest octet boundary. 



Figure 10.27.1: Packet Measurement Report IE 



10.28 Cell Identity List 



This is a variable length information element identifying a particular cell. 



Octet 1 
Octet 2 
Octet 3 



8 7 6 5 4 


3 


2 1 


lEI 


Length indicator 


The rest of the information element is coded as the 
the Cell Identity List IE defined in 3GPP TS 48.071 


value part of 



Figure 10.28.1: Cell Identifier IE 



10.29 IMEI 

This information element identifies the International Mobile Station Equipment Identity of the target MS (see 3GPP TS 
23.003). 
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8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2 


Length indicator 


Octets 3-10 


IMEI coded as tlie value part of the Mobile Identity IE defined in 
3GPPTS 24.008 (NOTE 1) 




NOTE 1 : The Type of identity f\e\6 in the Mobile Identity IE shall 
be ignored by the receiver. 



Figure 10.29.1: IMEI IE 



10.30 Velocity Data 



This is a variable length information element providing an estimate of a velocity data. 





8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2 


Length indicator 


Octet 3 

to 
Octet n 


The rest of the information element contains an octet sequence 
identical to that for Description of Velocity defined in 3GPP TS 
23.032. 



Figure 10.30.1 : Velocity Data IE 



Description of Velocity (octet 3 to n) 

This parameter gives an estimate of the velocity of an MS in speed and bearing and for certain descriptions, the 
accuracy of the estimate. The estimate is expressed in terms of the velocity description defined by 3GPP TS 23.032. 

1 0.31 Requested GANSS Assistance Data 

This is a variable length information element identifying the GANSS assistance data requested for an MS. 

Octet 1 
Octet 2 
Octet 3 
Octet m1 to 
Octet pi 

Octet pz-1+1 
to Octet pz 

Octet pn denote the last octet for GNSSn 
Figure 10.31.1: Requested GANSS Assistance Data IE, general structure 



IE! 


Length indicator 


H G F E D 


C 


B 1 A 1 


Generic assistance data for GNSS1 , 
Figure 10.31.2 


coding according to 


1 


Generic assistance data for GNSSz, 
Figure 10.31.2 


coding 


according to 
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Octet m 


L 


K 


J 


1 


GANSS ID 


Octet m+1 


T 


S 


R 


Q 


P O N M 


Octet m+2 




spare 


1 Information extension length indicator 


Octet m+3 

to 

Octet 

m+2+a 


Information extensions for assistance data (Conditional) 
Coding according to Figure 10.31.3 


Octet 
m+3+a 

to 

Octet 

m+5+a+2n 


Satellite related data (Conditional) 
Coding according to Figure 10.31.4 



a = length of 'Information extensions for assistance data' as indicated in 'Information extension 
length indicator', range 0..31 

Figure 10.31.2: Requested GANSS Assistance Data for one GNSS 

For each of the following bits, a '1' indicates that the GANSS assistance data is requested for that particular parameter 
and a '0' indicates that the data is not requested. For each bit, there may be one or more extension octets. These octets 
are defined in Figure 10.31.3 and they shall occur in 'Information extensions for assistance data ' field in the same order 
as they are introduced in Figure 10.31.3. For each bit set to '1', the respective octet or octets shall be present. The total 
amount of octets in 'Information extensions for assistance data ' field is indicated in 'Information extension length 
indicator'. 



Octet 3 in figure 10.31.1 defines the common assistance elements: 



bit A 
bitB 
bite 



GANSS Reference Time 
Reference Location 
GANSS Ionospheric Model 



bits D through H are Spare bits 



Octet m in figure 10.31.2 defines the generic assistance elements: 

GANSS ID (bits 1-4) 

This field indicates the GNSS for which the following assistance data is requested. (Range: - 8). 

0: Galileo 



bit I 
bit J 
bitK 
bitL 



GANSS Real-Time Integrity 

GANSS Differential Corrections 

GANSS Almanac 

GANSS Reference Measurement Information 



Octet m-nl in figure 10.31.2 defines the generic assistance elements: 



bitM 
0: 

1: 



bitN 

0: 

1: 

bitO 
bitP 
bitQ 
bitR 



GANSS Navigation Model 

GANSS Navigation Model is not requested - Satellite Related Data in figure 10.31.2 is not present 

for this GNSS.) 

GANSS Navigation Model is requested - Satellite Related Data in figure 10.31.2 is present for this 

GNSS.) 

GANSS Ephemeris Extension 

GANSS Ephemeris Extension is not requested 

GANSS Ephemeris Extension is requested 

GANSS Time Model GNSS-UTC 
GANSS Time Model GNSS-GNSS 
GANSS Data Bit Assistance 
GANSS Ephemeris Extension Check 
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0: 
1: 

bit S Spare 

bitT 

0: 

1: 



GANSS Ephemeris Extension Check is not requested 
GANSS Ephemeris Extension Check is requested 



Last Requested GANSS Assistance Data indicator 

More Requested GANSS Assistance Data is included in the IE 

This Requested GANSS Assistance Data is the last one in the IE 



The T bit indicates whether the current Requested GANSS Assistance Data for a GNSS as defined in figure 10.31.2 
is the last one. If bit T is set to '0', another structure of Figure 10.31.2 shall follow the current one. 

At least one of bits A to C, or I to Q shall be set to the value "1". 

Bits M, N and R are mutually exclusive for the additional assistance requests from the MS. In such case only one of 
these can be set to one at the same time. 

GANSS Differential Corrections Extension 

This octet shall be present when the GANSS Differential Corrections bit is set to '1' and absent otherwise. 



Extension 
Octet 1 



8 


7 


6 


5 


4 


3 


2 


1 


SB 


S7 


S6 


S5 


S4 


S3 


S2 


S1 



Figure 10.31.3a: Coding of Information Extension for GANSS Differential Corrections (conditional) 

Differential corrections are requested for each of the bits SI to S8 set to '1'. 
If GANSS ID indicates Galileo, the bits shall be interpreted as follows: 



it SI 


LI 


itS2 


E5a 


it S3 


E5b 


itS4 


E6 


itS5 


spare 


itS6 


spare 


itS7 


spare 


itS8 


spare 



GANSS Time Model GNSS-GNSS Extension 

This octet shall be present when the GANSS Time Model GNSS-GNSS bit is set to '1' and absent otherwise. 



Extension 
Octet 2 



8 


7 


6 


5 


4 3 1 2 


1 


spare 


spare 


spare 


spare 


spare 


spare 


Galileo 


GPS 



Figure 10.31.3b: Coding of Information Extension for GANSS Time Model GNSS-GNSS (conditional) 

The reference system for requested GANSS time models is as indicated in GANSS ID. The models are requested for 
each system with respective bit set to '1'. 



GANSS Data Bit Assistance Extension 

These octets shall be present when the GANSS Data Bit Assistance bit (bit Q) is set to '1' and absent otherwise. 
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Extension 

Octet 3 
Extension 

Octet 4 
Extension 

Octet 5 
Extension 

Octet 6 

Extension 
Octet 5+n 



8 


7 


6 5 


4 3 


2 


1 


GANSS TOD (range - 59) 


spare 


signals 


signal? 


signals 


signals 


signal4 


signals 


signal2 


signall 


GANSS Data Bit Interval 


Num Sat 


GANSS Sat ID 1 


Spare 






GANSS Sat ID N 


Spare 



Figure 10.31.3c: Coding of Information Extension for Data Bit Assistance (conditional) 

GANSS TOD 

This field contains the reference time of the first bit of the requested data in integer seconds in GANSS system time. 
The time is given as modulo 60 s from GANSS TOD. 

GANSS Signals: signall - signalS (Extension Octet 4) 

Each bit in Extension Octet 4 specifies the GANSS signal type of the GANSS Data Bit Assistance requested. The 
GANSS Signals value shall be interpreted as in Table A.59 of 3GPP TS 44.031 [4]. 

GANSS Data Bit Interval 

This field represents the time length for which the Data Bit Assistance is requested. The Data Bit Assistance shall be 
relative to the time interval (GANSS TOD, GANSS TOD + Data Bit Interval). 

The Data Bit Interval r, expressed in seconds, is mapped to a binary number K with the following formula: 

r=0.1*2'^ 

Value K=15 means that the time interval is not specified. 

The number of bits sent by the SMLC shall be estimated exploiting information about Data Bit Interval (sec) and 
Symbol Rate (sps). This number of bits shall be rounded up to the next higher multiple of 8. The total number of bits for 
each signal shall not exceed 1024 as defined in A.4.2.6.2 of 3GPP TS 44.031 [4]. 

Num Sat 

This field contains a binary representation of the number of GANSS satellites for which the Data Bit Assistance is 
requested. 



Range 0-15: 


1-15 

GANSS Sat ID 



no GANSS satellite ID is specified, octets 6 to 5H-n are not present. In this case. Data Bit 
Assistance is requested for all the satellites supposed in visibility; 
number of satellites for which the Data Bit Assistance is requested. 



This field is present only if Num Sat is not equal to 0; it contains a binary representation of the identity of a GANSS 
satellite for which the Data Bit Assistance request is applicable. 

GANSS Ephemeris Extension 

This octet shall be present when the GANSS Ephemeris Extension bit is set to "1" and absent otherwise. 



Extension 
Octet 5+n+1 



8 



Validity Time 
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Figure 10.31.3d: Coding of Information for Ephemeris Extension (conditional) 

Validity Time indicates the validity time for which the Ephemeris Extension should be valid in multiples of four hours. 
GANSS Ephemeris Extension Check 

These octets shall be present when the GANSS Ephemeris Extension Check bit is set to '1' and absent otherwise. 



Extension Octet 
5+n+1 



Extension Octet 
5+n+2 



8 7 6 5 4 


3 2 1 


GANSS Ephemeris Extension Begin Day 


GANSS Ephemeris 

Extension Begin TOD 

(MSB) 


GANSS 

Ephemeris 

Extension Begin 

TOD (LSB) 


GANSS Ephemeris Extension End Day 


Spare 



Figure 10.31.3e: Coding of Information Extension for Ephemeris Extension Check (conditional) 

These octets define the time duration of the Ephemeris Extension held by the MS. 

The GANSS Ephemeris extension Day (Begin and End) is the defined as the GANSS Day modulo 32. 

The GANSS Ephemeris extension TOD (Begin and End) is represented in hours into the GANSS day. 

(Note: Future extensions shall be added here) 

Satellite Related Data 

Satellite Related Data for Navigation Models (Figure 10.31.4) is present only when the GANSS Navigation Model bit is 
set to the value '1'. 

Octet m+3+a 
Octet m+4+a 
Octet m+5+a 
Octet m+6+a 
Octet m+7+a 
Octet m+8+a 

Octet m+5+2n+a 
Octet m+6+2n+a 

Figure 10.31.4: Coding of Satellite Related Data for Navigation IVIodels (conditional) 

GANSS Week (bits 5-8 octet m+3+a and octet m+4+a) 

This field contains a 12 bit binary representation of the GANSS Week of the assistance currently held by the MS. The 
most significant bit of the GANSS Week is bit 8 in octet m+3+a and the least significant bit is bit 1 in octet m+4+a. 

GANSS_Toe (octet m+5+a) 

This field contains a binary representation of the GANSS time of ephemeris in hours of the newest ephemeris set 
contained in handset memory (range 0-167). 

NSAT (octet m+6+a, bits 5-8) 

This field contains a binary representation of the number of satellites to be considered for the current GANSS assistance 
request. If the MS has no GANSS ephemeris data, this field shall be set to zero. If the MS has GANSS ephemeris data 
whose age exceeds the T-Toe limit, this field may be set to zero. If the SMLC receives a zero value for this field, it shall 
ignore the GANSS Week and GANSS_Toe fields and assume that the MS has no GANSS ephemeris data. 

T-Toe limit (octet m+6+a, bits 1-4) 
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7 1 6 
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3 1 2 
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GANSS Weel< 


Spare 


GANSS Weel< 
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lOD 1 


1 


GANSSSatID 1 




lOD 1 




lODn 


1 


GANSSSatID n 




lODn 1 
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This field contains a binary representation of the GANSS ephemeris age tolerance of the MS to the network in hours 
(range 0-10). 

GANSSSatID x (x = 1,2, ... n) (octet m+5+a + 2x, bits 1-6) 

This field is present only if NSAT exceeds zero and contains a binary representation of the identity of a GANSS 
satellite for which the assistance request is applicable. The number of satellite fields is indicated in the field NSAT. 

lOD X (x = 1,2, ... n) (bits 7-8 octet m+5+a+2x and octet m+6+a + 2x) 

This field is present only if NSAT exceeds zero and contains a binary representation of the Issue of Data held in the 
MS, which identifies the sequence number of the GANSS Navgation Model for a satellite x (x = 1, 2, ..., n). The SMLC 
shall derive the issue date and time for the lOD of each GANSS satellite x from the GANSS Week and GANSS_Toe 
fields (e.g. when a particular lOD value for a GANSS satellite x was issued more than once within the period of T-Toe 
limit). The most significant bit of the lOD x is bit 8 in octet m+5+a+2x and the least significant bit is bit 1 in octet 
m+6+a+2x. 



10.32 GANSS Positioning Data 



This is a variable length information element providing positioning data associated with a successful or unsuccessful 
location attempt for a target MS using GANSS. 



Octet 1 

Octet 2 

Octets 3 to n 



8 7 


6 1 5 1 4 1 


3 


1 2 1 


1 1 


lEI 


Length indicator 


IVlethod 


GANSS Id 




Usage 





Figure 10.32.1: GANSS Positioning Data IE 



Method : 




00 


MS-Based 


01 


MS- Assisted 


10 


Conventional 


11 


Reserved 



Coding of the GANSS Id: 

000 Galileo 

Coding of usage (bits 3-1) 



000 
001 
010 
Oil 
100 



Attempted unsuccessfully due to failure or interruption 

Attempted successfully: results not used to generate location 

Attempted successfully: results used to verify but not generate location 

Attempted successfully: results used to generate location 

Attempted successfully: case where MS supports multiple mobile based positioning methods and 

the actual method or methods used by the MS cannot be determined 



1 0.33 GANSS Location Type 



This is a variable length information element defining the constellation used when the Location Type / Positioning 
method is set to 00000100 or 00000101. 



Octet 1 
Octet 2 
Octet 3 
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Figure 10.33.1 : GANSS Location Type IE 
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When a bit is set to '1', it means that the corresponding system is refered by GANSS. 
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